Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-120

Text File | 1995-12-31 | 50.0 KB | 1,443 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sat, 04 Nov 95       Volume 3 : Issue 120

Today's Topics:

        Adding a Gestalt Handler
        Adobe Portable Document Format (Acrobat) Info
        Bug (memory leak) with NewGWorld?
        FPU and non-FPU comptuers in C
        How do I call a UPP?
        Q: name of file dropped on application
        STL Tutorial?
        Writing to Boot Blocks B-)
        grays vs. colors?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Scott Gruby)
Subject: Adding a Gestalt Handler
Date: Tue, 17 Oct 1995 22:05:06 -0700
Organization: QUALCOMM, Incorporated; San Diego, CA, USA

Prior to making my application PowerPC native, I was using the
GestaltValue library to add a gestalt handler that returned a value (the
number of email messages) so that another component could find out the
number of messages w/o AppleEvents or other routines. Since the library is
not PowerPC native, I've writing my own gestalt handler, but have run into
a problem. The problem is that I need to pass a new value into the gestalt
handler at certain times. How can I do this? Since the function is in the
system heap, I can register a new handler with a new value, but I've only
been able to pass in static values. Below are my handlers and the code
that I use to register/update the handler.

Any assistance would be appreciated.

Thanks.


static pascal OSErr  myGestaltFunction (OSType selector,long *response)
{
   long theValue = 0;
   // Need to set theValue to a global message count
   *response = theValue;
   return noErr;
}

static pascal OSErr  myRemoveGestaltFunction (OSType selector,long *response)
{
      *response = (long)-1;
      return gestaltUndefSelectorErr;
}


void UpdateMailCountGestalt(Boolean remove)
{
   long funcSize = 250;
   OSErr err;
   SelectorFunctionUPP  theGestaltFunction;
   Ptr      gestPtr = nil,oldGestPtr = nil;



   if (!remove)
      theGestaltFunction = NewSelectorFunctionProc(myGestaltFunction);
   else
      theGestaltFunction = NewSelectorFunctionProc(myRemoveGestaltFunction);

   funcSize = 200;
   gestPtr = NewPtrSysClear(funcSize);
   BlockMove(theGestaltFunction,gestPtr,funcSize);

   err = NewGestalt(kMyClass,(SelectorFunctionUPP)gestPtr);
   if (err)
      {
         err= ReplaceGestalt(kMyClass,(SelectorFunctionUPP)gestPtr,
         &(SelectorFunctionUPP)oldGestPtr);
      }
   if (oldGestPtr != nil)
      DisposePtr(oldGestPtr);
   if (err && gestPtr != nil)
      DisposePtr(gestPtr);



}

--
Scott Gruby
[e-mail]

+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 18 Oct 1995 14:03:27 GMT
Organization: University of Michigan

Here is a solution that I used in a recent project. The gestalt handler
manages
8-bytes of storage within itself (no cache-flushing is necessary!),
enough for
a long "version" value and a long "data" value/pointer/handle.

If you decide to use this, drop me a quick message.

Matt Slot, [e-mail]
<http://www.sils.umich.edu/~fprefect/>

// *
***********************************************************************
****** *
// *
***********************************************************************
****** *


// File "gestalt stub.h" -

#ifndef ____GESTALT_STUB_HEADER____
#define ____GESTALT_STUB_HEADER____

// * ************************ * //

#define kGestaltStubResource    'GStb'
#define kGestaltStubResID               128

#define kGestaltStubVersOffset  0x06
#define kGestaltStubDataOffset  0x0A

#define kGestaltStubSelector    'GStb'
#define kGestaltStubVersion             0L

typedef struct {
        long version;
        long data;
        } GestaltStub, *GestaltStubPtr;

// * ************************ * //
// Function Prototypes

short InstallGestaltStub(long type, long version, long data);
short LookupGestaltStub(long type, long version, long *response);

#endif  ____GESTALT_STUB_HEADER____


// *
***********************************************************************
****** *
// *
***********************************************************************
****** *


// File "gestalt stub.c" -

#include "gestalt stub.h"

// * ************************ * //

short InstallGestaltStub(long type, long version, long data) {
        short err = 0;
        Handle stubHdl;
        GestaltStubPtr stubData;
        SelectorFunctionUPP stubOut;

        if (Gestalt(type, (long *) &stubData) == gestaltUndefSelectorErr) {
                stubHdl = GetResource(kGestaltStubResource, kGestaltStubResID);
                if (! stubHdl) return(err = ResError());
                DetachResource(stubHdl);
                HLockHi(stubHdl);

                BlockMoveData(&version, *stubHdl + kGestaltStubVersOffset,
sizeof(version));
                BlockMoveData(&data, *stubHdl + kGestaltStubDataOffset, sizeof(data));

                err = NewGestalt(type, (SelectorFunctionUPP) *stubHdl);
                if (err) DisposeHandle(stubHdl);
                }
          else if (! stubData) return(err = -1);
          else {
                BlockMoveData(&version, &stubData->version, sizeof(version));
                BlockMoveData(&data, &stubData->data, sizeof(data));
                }

        return(err);
        }

// * ************************ * //

short LookupGestaltStub(long type, long version, long *response) {
        short err = 0;
        GestaltStubPtr stubData;

        *response = 0;
        stubData = 0;
        if (err = Gestalt(type, (long *) &stubData)) return(err);
        if (stubData->version != version) return(err = -1);

        *response = stubData->data;
        return(0);
        }


// *
***********************************************************************
****** *
// *
***********************************************************************
****** *


'GStb' Resource definition:

         LINK       A6,#$0000
         BRA.S      Anon1+$000E
         DC.L       0               ; Version storage
         DC.L       0               ; Data Ptr storage
         LEA        Anon1+$0006,A0
         MOVEA.L    $0008(A6),A1
         MOVE.L     A0,(A1)
         CLR.W      $0010(A7)
         UNLK       A6
         MOVEA.L    (A7)+,A0
         ADDQ.W     #$8,A7
         JMP        (A0)

 - or a straight hex dump -

        4E56 0000 6008 0000 0000 0000 0000
        41FA FFF6 226E 0008 2288 426F 0010
        4E5E 205F 504F 4ED0

// *
***********************************************************************
****** *
// *
***********************************************************************
****** *

Matt Slot, [e-mail]
<http://www.sils.umich.edu/~fprefect/>

---------------------------

>From [e-mail] (Stuart Mackinnon)
Subject: Adobe Portable Document Format (Acrobat) Info
Date: 16 Oct 1995 16:29:37 +1000
Organization: Zip Australia Pty Ltd

I was wondering, does anybody have the specifications of the adobe acrobat
file format (Portable Document Format - PDF)?

I wish to write an acrobat reader for another platform, and it seems that
the only official way for me to get this is to pay membership for the ADA
(Adobe Developer's Association). Since I live outside the US/Canada this
would mean an annual fee of US$700!!

Does anybody know of an easier way for me to get the acrobat file format?

Does anybody know an e-mail address of someone at adobe that I could
discuss my problem with?

Does anybody have the acrobat format specs that they could send me?

ANY help regarding this matter would be greatly appreciated.

Regards,

Stuart MacKinnon.

+++++++++++++++++++++++++++

>From [e-mail]
Date: Wed, 18 Oct 1995 19:59:10 GMT
Organization: VANISL Lug, Victoria, BC, Decus Canada

In article <45su4h$[e-mail]>, [e-mail] (Stuart Mackinnon) writes:
>I was wondering, does anybody have the specifications of the adobe acrobat
>file format (Portable Document Format - PDF)?
>
>I wish to write an acrobat reader for another platform, and it seems that
>the only official way for me to get this is to pay membership for the ADA
>(Adobe Developer's Association). Since I live outside the US/Canada this
>would mean an annual fee of US$700!!
>
>Does anybody know of an easier way for me to get the acrobat file format?
>
>Does anybody know an e-mail address of someone at adobe that I could
>discuss my problem with?
>
>Does anybody have the acrobat format specs that they could send me?
>
>ANY help regarding this matter would be greatly appreciated.
>
>Regards,
>
>Stuart MacKinnon.


There is a book published by Adobe/Addison-Wesley that describes the Portable
Document Format. It was published a couple of years ago, ~$30US.

A person I know received a magazine about publishing on the Web, sorry I don't
know the name, but inside the mag was a Adobe Acrobat CD Sampler and it had
the above manual in PDF format. This may be the same CD that Adobe is
advertising is PC Week (Sept 25) as the Adobe Acrobat On-Line Publishing Kit.
It is free if you call Adobe 1-800-521-1976 Ext E1559. Hope this helps.


+++++++++++++++++++++++++++

>From Manuel Veloso <[e-mail]>
Date: 21 Oct 1995 15:18:54 GMT
Organization: Active Paper, Inc

In article <45su4h$[e-mail]> Stuart Mackinnon,
[e-mail] writes:
>I wish to write an acrobat reader for another platform, and it seems that
>the only official way for me to get this is to pay membership for the ADA
>(Adobe Developer's Association).

good luck. Even with the .PDF format, you'll need a subset of a
normal PostScript interpreter to render the pages.

You can actually just open up a .PDF file in any text editor.
You might have to change the filetype to 'TEXT' first.
- -------------------
Manny Veloso
Digital Plumber
Active Paper, Inc.
http://www.apix.com
Purveyors of fine MagicCap products
- -------------------
"Nothin' out there you haven't seen before now."


---------------------------

>From [e-mail] (K. Beeghly)
Subject: Bug (memory leak) with NewGWorld?
Date: 15 Oct 1995 23:05:43 GMT
Organization: University of Washington


Hi, I am cross-posting this to c.s.m.p.codewarrior and c.s.m.p.help,
since at this point I do not know if this is a bug w/CW or with NewGWorld.


I have the following code:

short           i;
Rect            r;
OSErr           theErr;
GWorldPtr       arr[20];
short           nNum;

        nNum = 18;
        for(i=0; i<nNum; i++)
        {
                SetRect(&r, 0, 0, 80, 53);
                theErr = NewGWorld(&arr[i], 32, &r, nil, nil, 0L);
        }
        // Note: the following is optional.  My code didn't Dispose the GWorld
        // until much later in the code, but I added it here to see if it
        // would make a difference (whicht didn't).
        for(i=0; i<nNum; i++)
                DisposeGWorld(arr[i]);

When I run this code and use he newest version of ZoneRanger (1.6 - way
to go Metrowerks! 1.6 is the best version ever!) to look for memory
leaks, ZR tells me that the code leaks several pointers (each
256 bytes long).  The number of pointers leaked depends on the number of
times NewGWorld is called.

RESULTS:
        nNum    # of pointers leaked
        2               0
        3               0
        4               0
        5               0
        6               0
        7               1
        8               1
        9               1
        10              2
        11              2
        12              3
        13              3
        14              4
        15              4
        16              4
        17              5
        18              5


As you can see, the loss on not exactly proportional to nNum.

Is this documented?  Had anyone else run into this problem?  NewGWorld
doesn't create any pointers, so why am I getting a pointer memory leak?!?

I am in great need of an expliantion of this.  If you have any comments
or suggestions, please e-mail me at [e-mail] or
[e-mail].


Thanks,



Jeff

PS.  Oh yea, here are some other things you may want to know:
        * I have plenty of RAM allocated for the application
        * I'm running on a IIci under 7.5.0


+++++++++++++++++++++++++++

>From [e-mail] (Tim Dierks)
Date: Tue, 17 Oct 1995 01:45:37 -0700
Organization: Best Internet Communications

In article <45s447$[e-mail]>, [e-mail]
(K. Beeghly) wrote:
> [ Code snippet ommitted: allocates a bunch of GWorlds then disposes of them ]
>
>When I run this code and use he newest version of ZoneRanger (1.6 - way
>to go Metrowerks! 1.6 is the best version ever!) to look for memory
>leaks, ZR tells me that the code leaks several pointers (each
>256 bytes long).  The number of pointers leaked depends on the number of
>times NewGWorld is called.
>
> [ Table omitted: # of pointers leaked increases as number of calls to
NewGWorld() increases ]
>
>Is this documented?  Had anyone else run into this problem?  NewGWorld
>doesn't create any pointers, so why am I getting a pointer memory leak?!?

When you create a new handle, the pointer that points at the memory (a
"master pointer") needs to be reserved for your block. Since you've got a
pointer to it, it has to be in a non-relocatable block. When the Memory
Manager runs out of free master pointers, it allocates a new block of 64
(by default). This block is 64*sizeof(void *) long = 256 bytes.

The Memory Manager doesn't have the ability to ever free a master pointer
block, so it's a "leak", all right; it's allocated and never freed.
However, it does reuse master pointers, so as long as the number of
handles you create peaks at some point, so will your need for master
pointer blocks.

When you create a whole bunch of GWorlds, you use up a bunch of master
pointers for the handles that get created. The Memory Manager is creating
master pointer blocks to store these master pointers.

If you are also locking blocks or using non-relocatable blocks, these can
fragment your heap. To avoid this, you should call MoreMasters() several
times at the start of your program. This call allocates a new master
pointer block; if you call it enough times, your app will never run out of
free master pointers, and so it will never allocate another master pointer
block. This puts all the nonrelocatable master pointer blocks at the
bottom of the heap where they  don't fragment your memory.

The best way to determine how many times to call MoreMasters() is
empirically; exercise your app and then count how many master pointer
blocks you needed. Call MoreMasters() at least that many times. I usually
add one or two blocks to cover emergencies. To determine how many master
pointer blocks you've got, break into MacsBug and type "hd n"; this will
display all the non-relocatable blocks in your heap. All the blocks that
are 256 (0x100) bytes long are probably master pointer blocks.

Enjoy,
 - Tim

--
Tim Dierks - Software Haruspex - [e-mail]
If you can't lick 'em, stick 'em on with a big piece of tape. - Negativland

+++++++++++++++++++++++++++

>From [e-mail] (Ari Halberstadt)
Date: Mon, 16 Oct 1995 16:47:13 -0400
Organization: North Shore Access/Eco Software, Inc; ([e-mail])

In article <45s447$[e-mail]>, [e-mail]
(K. Beeghly) wrote:
>When I run this code and use he newest version of ZoneRanger (1.6 - way
>to go Metrowerks! 1.6 is the best version ever!) to look for memory
>leaks, ZR tells me that the code leaks several pointers (each
>256 bytes long).  The number of pointers leaked depends on the number of
>times NewGWorld is called.

Whenever you see 256 byte pointers being allocated when you make
apparently unrelated allocations, it is most likely that the Memory
Manager is allocating additional master pointer blocks. This is especially
likely with calls like NewGWorld, which allocate many handles. Using
ZoneRanger, you can determine the number of master pointer blocks that
your application needs by dividing the number of handles by 64. Then,
early in your application's initialization, call the MoreMaster procedure
the required number of times. This will avoid heap fragmentation, since
the master pointers will be allocated low in the heap. For instance, you
could use the following code:

   SetApplLimit(GetApplLimit() - additionalStackSize);
   MaxApplZone();
   while (masters-- > 0)
      MoreMasters();

Use this code before calling InitGraf.

-- Ari Halberstadt ([e-mail], [e-mail])
For latest versions of some of my Macintosh software try <ftp://ftp.shore.net/members/ari>.

+++++++++++++++++++++++++++

>From [e-mail] (Chris Burns)
Date: Thu, 19 Oct 1995 16:54:56 +1300
Organization: HyperMedia Unit, Comp Sci, Auckland University

In article <45s447$[e-mail]>, [e-mail]
(K. Beeghly) wrote:

>I have the following code:
>
>short           i;
>Rect            r;
>OSErr           theErr;
>GWorldPtr       arr[20];
>short           nNum;
>
>        nNum = 18;
>        for(i=0; i<nNum; i++)
>        {
>                SetRect(&r, 0, 0, 80, 53);
>                theErr = NewGWorld(&arr[i], 32, &r, nil, nil, 0L);
>        }
>        // Note: the following is optional.  My code didn't Dispose the GWorld
>        // until much later in the code, but I added it here to see if it
>        // would make a difference (whicht didn't).
>        for(i=0; i<nNum; i++)
>                DisposeGWorld(arr[i]);
>
>When I run this code and use he newest version of ZoneRanger (1.6 - way
>to go Metrowerks! 1.6 is the best version ever!) to look for memory
>leaks, ZR tells me that the code leaks several pointers (each
>256 bytes long).  The number of pointers leaked depends on the number of
>times NewGWorld is called.
>
>RESULTS:
>        nNum    # of pointers leaked
>        2               0
>        3               0
>        4               0
>        5               0
>        6               0
>        7               1
>        8               1
>        9               1
>        10              2
>        11              2
>        12              3
>        13              3
>        14              4
>        15              4
>        16              4
>        17              5
>        18              5
>
>
>As you can see, the loss on not exactly proportional to nNum.
>
>Is this documented?  Had anyone else run into this problem?  NewGWorld
>doesn't create any pointers, so why am I getting a pointer memory leak?!?

Can you say "_MoreMasters"?  Non-relocatable blocks of 256 bytes (0x100)
are exactly what the _MoreMasters call allocates. These blocks contain
master pointers for your applications relocatable block use. This would
make sense as the Memory Manager calls _MoreMasters when it runs out of
free master pointers. This is really bad for your apps memory usage as you
end up with non-relocatable blocks scattered all over your heap - bad
news.

The _MoreMasters trap allocates master pointer blocks with several master
pointers in them. The number of master pointers per block is stored in the
heap header structure for your heap. You need to estimate the _maximum_
number of master pointers your program uses and use this as a guide. Allow
for handles that the OS and toolbox allocate (scrap, window regions,
colour tables, resources, etc).

Specifically, remember that a GWorldPtr points to a non-relocatable block
(no master pointer needed) that contains fields including:

PixMapHandle portPixMap;
Handle grafVars;
RgnHandle visRgn;
RgnHandle clipRgn;
PixPatHandle bkPixPat;
PixPatHandle pnPixPat;

All of which are handle based (reqire one master pointer each). Some of
the structures they reference also have handle based storage.


You can either:

1) Call _MoreMasters a suitable number of times at the start of your
program. This is compatable and safe, but has a small overhead.

2) Change the number of master pointers per block to how many you want,
then call _MoreMasters once. Remember to change it back to something
sensible after.

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x5602
Fax:      [phone]                         Async, Therefore I Am.
- ---------------------------------------------------------------------

---------------------------

>From Daniel Cote <[e-mail]>
Subject: FPU and non-FPU comptuers in C
Date: Tue, 10 Oct 1995 16:06:18 GMT
Organization: University of Toronto - Dept. of Physics


Does anyone know if it is possible to generate one (and only one) C code
that would run on both FPU and non-FPU computers, using the FPU when
present, and using the non-fpu routines when no FPU is present...?

It seems impossible because the adresses of each routine is resolved at
compile time, which results in code that can not "decide" which routine
to use. Is it a limit of the C language?  Should I use assemlby language?

It seems to me that I might be able to link two different CODE
ressources (one with FPU, one without FPU) and throw away the one I
don't need after I checked for the existance of FPU.  Does anyone know
anything about that?



- -----------
Daniel Cote                       "If it moves, it's Biology.
U of Toronto Physics Dept.             If it stinks, it's Chemistry.
[e-mail]                  If it doesn't work, it's Physics."

                       Support ISO-8859-1 Standard!



+++++++++++++++++++++++++++

>From [e-mail] (James Deline)
Date: Tue, 10 Oct 1995 23:18:52 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

Daniel Cote ([e-mail]) wrote:

: Does anyone know if it is possible to generate one (and only one) C code
: that would run on both FPU and non-FPU computers, using the FPU when
: present, and using the non-fpu routines when no FPU is present...?

[snip]

I did something like that in a program I wrote.  I compiled one source
file in its own project with the floating point options set.  All of the
function names in this source file differed from the original file in
that the names began with "fp_".  I then included this project in my
other project (under Think C) and everytime I needed to call one of the
functions in that particular source file, I checked a global variable
that I initialized at runtime to determine if I could call the floating
point routines or not.  I then called either "fp_function" or "function"
depending upon the global variable value.

Not pretty, but it worked most excellently.  The main problem is when you
change the source code in one file you have to make the same changes in
the other one, recompile it, and then re-include it in your main project.

jd



+++++++++++++++++++++++++++

>From [e-mail] (Hoshi Takanori)
Date: 18 Oct 1995 10:10:14 GMT
Organization: Software Research Associates, Inc.,Japan

In article <[e-mail]> [e-mail] (James Deline) writes:

> Not pretty, but it worked most excellently.  The main problem is when you
> change the source code in one file you have to make the same changes in
> the other one, recompile it, and then re-include it in your main project.

Why don't you use the standard cpp technique:

#ifdef FLOATING_POINT
#ifdef __STDC__
#define FP(func) fp_##func
#else
#define FP(func) fp_/**/func
#endif
#else
#define FP(func) func
#endif

double FP(foo)(double arg1, ... );

hoshi

---------------------------

>From [e-mail] (Tim DeBenedictis)
Subject: How do I call a UPP?
Date: Fri, 13 Oct 1995 17:19:42 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

I have this situation where I am given a UPP, and I want to call the
function it refers to from within my own code.  Now, I know that on a 68K
Mac, a UPP is an actual function pointer, so all I have to do is:

result = (*upp) ( arg1, arg2, arg3, ... );

On the PowerPC, the UPP is -not- the actual function pointer, but instead
contains the function pointer, plus some other descriptive stuff.  What
do I do here?  Is there any easy answer?

-Tim DeBenedictis
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Daniel Azuma)
Date: Sun, 15 Oct 1995 22:24:38 -0700
Organization: California Institute of Technology, Pasadena

[e-mail] (Tim DeBenedictis) wrote:

> I have this situation where I am given a UPP, and I want to call the
> function it refers to from within my own code.  Now, I know that on a 68K
> Mac, a UPP is an actual function pointer, so all I have to do is:
>
> result = (*upp) ( arg1, arg2, arg3, ... );
>
> On the PowerPC, the UPP is -not- the actual function pointer, but instead
> contains the function pointer, plus some other descriptive stuff.  What
> do I do here?  Is there any easy answer?

The universal headers supply macros for you to use to call the UPP. For
example, to call a modal dialog filter proc, use:

ModalFilterUPP myUPP;
DialogRef theDialog;
EventRecord theEvent;
short itemHit;
Boolean result;

result = CallModalFilterProc(myUPP, theDialog, &theEvent, &itemHit);

These macros will expand to either the 68k code you described above, or
the appropriate CFM call to CallUniversalProc(), depending on how your
code is being compiled.

If you are constructing your own UPP type, you'll need to create your own
macro. Probably the best way to learn how is to study the examples given
in the universal headers.


Hope this helps.

Dan

                                                                +-+
================================================================| |=======
 \ _____ Daniel Azuma _____ \ "See what love the Father has  +--+ +--+  /
  \ <[e-mail]> \  given us, that we should be  +--+ +--+ /
   \    Caltech CS Student    \  called children of God..."     | |   /
    \  Mac Programming Artist  \            ---1 John 3:1       | |  /
    ============================================================| |===
                                                                | |
                                                                +-+

+++++++++++++++++++++++++++

>From [e-mail] (Michael Keeley)
Date: 15 Oct 1995 22:16:38 GMT
Organization: Computer Graphics Lab, University of Otago

Tim DeBenedictis ([e-mail]) wrote:
> I have this situation where I am given a UPP, and I want to call the
> function it refers to from within my own code.  Now, I know that on a 68K
> Mac, a UPP is an actual function pointer, so all I have to do is:

> result = (*upp) ( arg1, arg2, arg3, ... );

> On the PowerPC, the UPP is -not- the actual function pointer, but instead
> contains the function pointer, plus some other descriptive stuff.  What
> do I do here?  Is there any easy answer?

While the UPP is not the function pointer, is does point to glue which
will do any necessary mode swapping, call your function, and then swap
the mode back. So you should be able to call the UPP anyway (That's
why it's called Universal).

Mike.

--
===========================================================
 Michael Keeley                     Dept. Computer Science
 [phone]                   University of Otago
 [e-mail]           New Zealand
===========================================================

+++++++++++++++++++++++++++

>From [e-mail] (Erichsen)
Date: Sun, 15 Oct 1995 17:53:59 -0700
Organization: Disorganized

Tim DeBenedictis ([e-mail]) wrote:
> I have this situation where I am given a UPP, and I want to call the
> function it refers to from within my own code.  Now, I know that on a 68K
> Mac, a UPP is an actual function pointer, so all I have to do is:

> result = (*upp) ( arg1, arg2, arg3, ... );

> On the PowerPC, the UPP is -not- the actual function pointer, but instead
> contains the function pointer, plus some other descriptive stuff.  What
> do I do here?  Is there any easy answer?

If the UPP is for a Toolbox routine, there's most likely a macro that you
can call to call the routine correctly for 680x0 or PowerPC code. Look in
the header file of the mananger the routine is related to for a
CallxxxProc macro (ie. Control-related routine would be in Controls.h. If
not, you can use CallUniversalProc to call the routine.

For example, to call a control action proc, you use:

CallControlActionProc( userRoutine, theControl, partCode )

+++++++++++++++++++++++++++

>From [e-mail] (Ken Prehoda)
Date: Thu, 19 Oct 1995 18:02:22 -0500
Organization: Univ of Wisc-Madison, Dept of Biochemistry

In article <45s186$[e-mail]>, [e-mail]
(Michael Keeley) wrote:

: Tim DeBenedictis ([e-mail]) wrote:
: > I have this situation where I am given a UPP, and I want to call the
: > function it refers to from within my own code.  Now, I know that on a 68K
: > Mac, a UPP is an actual function pointer, so all I have to do is:
:
: > result = (*upp) ( arg1, arg2, arg3, ... );
:
: > On the PowerPC, the UPP is -not- the actual function pointer, but instead
: > contains the function pointer, plus some other descriptive stuff.  What
: > do I do here?  Is there any easy answer?
:
: While the UPP is not the function pointer, is does point to glue which
: will do any necessary mode swapping, call your function, and then swap
: the mode back. So you should be able to call the UPP anyway (That's
: why it's called Universal).

The problem is that for 68k code a UPP _is_ a function pointer so trying
to call it from PPC will cause bad things to happen.  What you need to do
is use calluniversalproc() to be safe.

--
Ken Prehoda, [e-mail]

---------------------------

>From [e-mail] (boy wonder)
Subject: Q: name of file dropped on application
Date: 16 Oct 1995 21:33:33 GMT
Organization: University of New Brunswick, Fredericton, NB, Canada

How can I get the name of the file that I drop on my application?
I need to read data from a text file. Right now, I read from
hardcoded 'datafile', which means that I must rename my files
each time I want a new one read.  This is a terrible nuissance, one
that my mac should be able to handle easily.  But how do I do it?
I am using Symantec C++.

Are argv and argc the way to go? Or do those make any sense in
mac programming? The manuals I have are either unrelated to
the mac environment, or are hopelessly convoluted.

Thanks, Mike.

+++++++++++++++++++++++++++

>From [e-mail] (Daniel T.)
Date: Tue, 17 Oct 1995 18:23:55 -0400
Organization: CyberGate

In article <45uj3d$[e-mail]>, [e-mail]
(boy wonder) wrote:

>How can I get the name of the file that I drop on my application?
>I need to read data from a text file. Right now, I read from
>hardcoded 'datafile', which means that I must rename my files
>each time I want a new one read.  This is a terrible nuissance, one
>that my mac should be able to handle easily.  But how do I do it?
>I am using Symantec C++.
>
>Are argv and argc the way to go? Or do those make any sense in
>mac programming? The manuals I have are either unrelated to
>the mac environment, or are hopelessly convoluted.

The information you seek in is the Segment Loader section of IM (don't
know what book). argv and argc don't work you have to call the functions
below instead.

When the Finder starts up your application, it passes along a list of
documents selected by the user to be printed or opened, if any.
- ------------------
extern pascal void CountAppFiles(short *message, short *count);

The above function returns the number of selected documents in the count
parameter, and the number in the message parameter that indicates whether
the documents are to be  opened or printed.
- ------------------
extern pascal void GetAppFiles(short index, AppFile *theFile);

The index parameter indicates the file for which information should be
returned; it must be between 1 and the number returned by CountAppFiles,
inclusive.
- ------------------
extern pascal void ClrAppFiles(short index);

ClrAppFiles changes the Finder information passed to your application
about the specified file such that the Finder knows you've processed the
file.
- ----------------+------------------------------------------
Daniel T.         |  SCA: Lord Nicolas Bradwater, KMoC
Clearwater, FL    |  IGS: DanielT
[e-mail] |  IRC: DanielT

+++++++++++++++++++++++++++

>From [e-mail] (Daniel Azuma)
Date: Wed, 18 Oct 1995 19:42:55 -0700
Organization: California Institute of Technology, Pasadena

In article <45uj3d$[e-mail]>, [e-mail]
(boy wonder) wrote:

> How can I get the name of the file that I drop on my application?
> I need to read data from a text file. Right now, I read from
> hardcoded 'datafile', which means that I must rename my files
> each time I want a new one read.  This is a terrible nuissance, one
> that my mac should be able to handle easily.  But how do I do it?
> I am using Symantec C++.
>
> Are argv and argc the way to go? Or do those make any sense in
> mac programming? The manuals I have are either unrelated to
> the mac environment, or are hopelessly convoluted.

argv and argc will not help you here. Getting info on drag-and-drop files
requires you to use AppleEvents. (Actually, there is a pre-AppleEvent
method but it is not much easier and is no longer really supported.) The
Finder sends you info on the files dropped on your application through an
"odoc" event.

What you need is a copy of Inside Macintosh: Interapplication
Communications. You can also probably find drop-box application frameworks
on the net that include the AppleEvent code pre-written so you don't have
to learn it. I think there was one called "BoxMaker++" or something like
that. I've never used these so I can't comment on how well they work.

In general, drag-and-drop is a Macintosh thing, so you'll need to know how
to work with the Mac File Manager API and so forth in order to use it. If
you just want to write a quick-and-dirty program using the ANSI libraries,
you may be better off redirecting standard in. Your Symantec C++ user
manual will tell you how to accomplish that. (I use Metrowerks, and they
provide a function called "ccommand()", defined in <console.h>, which
handles this sort of thing.)

Give your manuals another try. Symantec's manual is actually fairly well done.

Dan

                                                                +-+
================================================================| |=======
 \ _____ Daniel Azuma _____ \ "See what love the Father has  +--+ +--+  /
  \ <[e-mail]> \  given us, that we should be  +--+ +--+ /
   \    Caltech CS Student    \  called children of God..."     | |   /
    \  Mac Programming Artist  \            ---1 John 3:1       | |  /
    ============================================================| |===
                                                                | |
                                                                +-+

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Thu, 19 Oct 1995 01:05:04 GMT
Organization: ISIS International

In article <daniel_t-1710951823560001@10.0.2.15>,
[e-mail] (Daniel T.) wrote:

>
>The information you seek in is the Segment Loader section of IM (don't
>know what book). argv and argc don't work you have to call the functions
>below instead.

>extern pascal void CountAppFiles(short *message, short *count);
>extern pascal void GetAppFiles(short index, AppFile *theFile);
>extern pascal void ClrAppFiles(short index);

Those functions are obsolete and shouldn't be used - they're only present
for backward compatibility in 68K applications. They aren't available for
native PowerPC code.

AppleEvents should be used instead.


--
Mike Cohen - [e-mail]
Home page: ftp://ftp.netcom.com/pub/is/isis/home.html
Sound is the same for all the world - Youssou N'dour, "Eyes Open"

---------------------------

>From [e-mail] (Kirk A. Stork)
Subject: STL Tutorial?
Date: Tue, 17 Oct 1995 18:29:52 -0700
Organization: Naval Postgraduate School, Monterey, CA

Is there a tutorial or users guide for the STL (other than the document
from HP that comes on the CW CD)?

Or...would anyone be willing to share some example code using the STL?

As a relative newbie to C++ programming, the STL looks extremely useful,
but is a bit beyond my technical knowledge.

+++++++++++++++++++++++++++

>From [e-mail] (Jim Hill)
Date: Thu, 19 Oct 1995 07:17:53 GMT
Organization: biological <-- hey! a one-word oxymoron!

In article <[e-mail]>,
[e-mail] (Kirk A. Stork) wrote:

>Is there a tutorial or users guide for the STL (other than the document
>from HP that comes on the CW CD)?

You want <http://www.cs.rpi.edu/~musser/stl.html>.

Jim
--
Jim Hill              Contents public domain and worth $.02 more than you paid.
[e-mail]     PGPrint: 6B 85 76 D1 EF BA 2C 78  12 25 8A 5A BF F3 37 7E

+++++++++++++++++++++++++++

>From [e-mail] (Larry Gerndt)
Date: 19 Oct 1995 23:09:24 GMT
Organization: Portal Communications (shell)

In article <[e-mail]>,
[e-mail] (Kirk A. Stork) wrote:

> Is there a tutorial or users guide for the STL (other than the document
> from HP that comes on the CW CD)?
>
> Or...would anyone be willing to share some example code using the STL?
>
> As a relative newbie to C++ programming, the STL looks extremely useful,
> but is a bit beyond my technical knowledge.

I bumped into a great STL reference book by a company called
ObjectSpace.   The title is "STL<ToolKit>", cutely named.
I'd recommend it.

- -------------------------| Into the Woods
Larry Gerndt               | It's always when
[e-mail]   | You think at last you're through and then
[phone]             | Into the woods you go again
- -------------------------| To take another journey -- Stephen Sondheim


---------------------------

>From [e-mail] (The Grinch)
Subject: Writing to Boot Blocks B-)
Date: Tue, 17 Oct 1995 16:24:33 -0400
Organization: Vortex Software

Anyone out there know how I can write to the boot blocks of an HD? Thanks
much for the input.

ÑThe Grinch

+++++++++++++++++++++++++++

>From [e-mail] (Steve Holzworth)
Date: Wed, 18 Oct 1995 20:17:45 GMT
Organization: SAS Institute Inc.

Matt Slot <[e-mail]> writes:

>The Grinch, [e-mail] writes:
> > Anyone out there know how I can write to the boot blocks of an HD?
>Thanks
> > much for the input.

>One suggestion would be to write your information to a DiskCopy image
>file,
>then apply the changes to a floppy or hard disk directly from the image.

>Matt

Issue the appropriate SCSI commands directly to the disk via the Mac
SCSI Manager. (See the SCSI Manager manual from Inside Mac). The boot
blocks are at specified positions on the volume. SCSI drives are
addressed as sequential logical blocks from 0-NNN, irrespective of
platters, heads, cylinders et al of the physical medium.
--
Steve Holzworth
[e-mail]                    "Do not attribute to poor spelling
SAS Institute   x6872               That which is actually poor typing..."
SAS/Macintosh Development Team                            - me
Cary, N.C.

+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: Thu, 19 Oct 1995 00:39:06 -0700
Organization: MindVision Software

In article <[e-mail]>, [e-mail] (Steve Holzworth) wrote:

> Matt Slot <[e-mail]> writes:
>
> >The Grinch, [e-mail] writes:
> > > Anyone out there know how I can write to the boot blocks of an HD?
> >Thanks
> > > much for the input.
>
> >One suggestion would be to write your information to a DiskCopy image
> >file,
> >then apply the changes to a floppy or hard disk directly from the image.
>
> >Matt
>
> Issue the appropriate SCSI commands directly to the disk via the Mac
> SCSI Manager. (See the SCSI Manager manual from Inside Mac). The boot
> blocks are at specified positions on the volume. SCSI drives are
> addressed as sequential logical blocks from 0-NNN, irrespective of
> platters, heads, cylinders et al of the physical medium.

NO! Don't use SCSI commands. To write boot blocks, simply do a _PBWrite
and set the ioVRefNum to the drive number and ioRefNum to the driver
reference number.

This will write to the volume as if it were one big file.

Steve Kiene
MindVision Software

+++++++++++++++++++++++++++

>From Dave Overton <[e-mail]>
Date: Thu, 19 Oct 1995 13:26:17 GMT
Organization: DataStream Imaging Systems, Inc.

You can write directly to the drive by using direct device driver calls.
You can get the device driver reference number from the Volume Queue.
Then just issue Read/Write calls to that driver.
Here is some code which writes to the second boot block on a floppy.

        ParamBlockRec           dParams;


        dParams.ioParam.ioRefNum = -5;                          // floppy disk driver refnum
                                                                                                // you would use hard drive driver ref
        dParams.ioParam.ioVRefNum = whichDrive;         // 1 or 2 for a floppy, ? for
hard drive
        dParams.ioParam.ioPosMode = fsFromStart;
        dParams.ioParam.ioPosOffset = 512;
        dParams.ioParam.ioReqCount = 512;
        dParams.ioParam.ioBuffer = diskBuffer;
        error = PBWrite ( &dParams, false );
        if ( error != noErr ) {
        }

Hope this helps
daveo


---------------------------

>From [e-mail] (Carl Bevil)
Subject: grays vs. colors?
Date: 4 Oct 1995 00:23:20 GMT
Organization: Information Resources and Technology

Can anyone tell me how to determine if the current monitor is in colors or
grays mode (like the setting in the monitors control panel).  I am writing a
program and I need to detect if the user has set their monitor to grays or
not.

reply in e-mail if possible.

Thanks,


--


Carl
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Tim Dierks)
Date: Wed, 04 Oct 1995 00:35:52 -0700
Organization: Best Internet Communications

In article <44sk5o$[e-mail]>, [e-mail] (Carl
Bevil) wrote:
>Can anyone tell me how to determine if the current monitor is in colors or
>grays mode (like the setting in the monitors control panel).  I am writing a
>program and I need to detect if the user has set their monitor to grays or
>not.

For any patricular GDevice:

isColor = TestDeviceAttribute (gdh, gdDevType);

Inside Macintosh: Imaging With QuickDraw page 5-31.

--
Tim Dierks - Software Haruspex - [e-mail]
If you can't lick 'em, stick 'em on with a big piece of tape. - Negativland

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 4 Oct 1995 15:31:36 GMT
Organization: UCLA, Computer Science Department

In article <44sk5o$[e-mail]> [e-mail] (Carl Bevil) writes:
>Can anyone tell me how to determine if the current monitor is in colors or
>grays mode (like the setting in the monitors control panel).  I am writing a
>program and I need to detect if the user has set their monitor to grays or
>not.

There is a bit in the deviceFlags field of the graphics device record which
indicates whether the device is color or grayscale (I don't remember which
bit off the top of my head---try looking in IM: Imaging With Quickdraw.)

That said, if you are doing drawing differently for color vs. grayscale
devices, you should be using DeviceLoop() so you can do the right thing
if your window spans two monitors, one which is set for colors and one
which is set for grayscale. In this case, the deviceFlags are passed as a
parameter to your callback from DeviceLoop(). Look it up; it's way cool.
(DeviceLoop() is also described in IM: Imaging w/Quickdraw.)

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
- -------------------------------------+---------------------------------------
(Insert Disclaimer Here)               | Who's the man ridin' in the sun?
UCLA Bruins--1995 NCAA Men's Basketball| Who's the man with the itchy gun?
             National Champions (yea!) | Who's the man who kills for fun?
Internet: [e-mail]  | Psycho Dad, Psycho Dad, PSYCHO DAD!

+++++++++++++++++++++++++++

>From [e-mail] (Jeremy Roussak)
Date: 8 Oct 1995 08:04:37 GMT
Organization: Queen Mary & Westfield College, London, England

In article <[e-mail]>
[e-mail] (Tim Dierks) writes:

> In article <44sk5o$[e-mail]>, [e-mail] (Carl
> Bevil) wrote:
> >Can anyone tell me how to determine if the current monitor is in colors or
> >grays mode (like the setting in the monitors control panel).  I am writing a
> >program and I need to detect if the user has set their monitor to grays or
> >not.
>
> For any patricular GDevice:
>
> isColor = TestDeviceAttribute (gdh, gdDevType);

However, bear in mind that this doesn't tell you whether the monitor
itself is colour or greyscale. It's perfectly possible to use the
Monitors Control Panel to put a greyscale monitor in "colour" mode (I
do it myself, since it seems to improve the display on my Radius 2-bit
Pivot monitor). Software will then tell you that the monitor is colour,
but it ain't...

Jeremy

+++++++++++++++++++++++++++

>From [e-mail] (Timothy C. Delaney)
Date: Wed, 18 Oct 1995 15:32:46 +1000
Organization: Boxes Objects Links Design Pty Ltd

In article <4580ml$[e-mail]>, [e-mail] (Jeremy
Roussak) wrote:

> In article <[e-mail]>
> [e-mail] (Tim Dierks) writes:
>
> > In article <44sk5o$[e-mail]>, [e-mail] (Carl
> > Bevil) wrote:
> > >Can anyone tell me how to determine if the current monitor is in colors or
> > >grays mode (like the setting in the monitors control panel).  I am
writing a
> > >program and I need to detect if the user has set their monitor to grays or
> > >not.
> >
> > For any patricular GDevice:
> >
> > isColor = TestDeviceAttribute (gdh, gdDevType);
>
> However, bear in mind that this doesn't tell you whether the monitor
> itself is colour or greyscale. It's perfectly possible to use the
> Monitors Control Panel to put a greyscale monitor in "colour" mode (I
> do it myself, since it seems to improve the display on my Radius 2-bit
> Pivot monitor). Software will then tell you that the monitor is colour,
> but it ain't...
>
> Jeremy

   The way I would do it (I've just been setting up something similar) in
order to get the best of both worlds would be something like ...

isColour = TestDeviceAttribute(gdh, gdDevType);
hasColour = HasDepth(gdh, 2, gdDevType, 1));

   Thus you know both ... I specified 2 bit depth because every monitor which
supports colour will support 2 bits of it ... subsitute another value
depending on your needs.

--

                                       _/_/_/_/
   __|  __|        _/_|     _/_/_/      _/_|     _/_/_/
  _/_| _/_|      _/  _|   _/          _/  _|   _/    _/
 -/ _|_/ _|    _/_/_/_|  _/ _/_/_/  _/_/_/_|  _/    _/
_/  __/  _|  _/      _|  _/_/_/   _/      _|  _/_/_/

Tim Delaney
   Mac/PC Programmer, Bold Pty Ltd   [e-mail]
   Student, Uni of Wollongong         [e-mail]

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Wed, 18 Oct 1995 10:58:11 -0400
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] (Timothy C. Delaney) writes:
>    The way I would do it (I've just been setting up something similar) in
> order to get the best of both worlds would be something like ...
>
> isColour = TestDeviceAttribute(gdh, gdDevType);
> hasColour = HasDepth(gdh, 2, gdDevType, 1));
>
>    Thus you know both ... I specified 2 bit depth because every monitor which
> supports colour will support 2 bits of it ... subsitute another value
> depending on your needs.

Ack! No, please. The very fine Radius multisync 17" monitor in front of
me (attached to a Radius video card, I don't know what type) supports
1, 4, 8, 16, and 32 bits of color -- but not 2 bits. Your code
wouldn't work.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Don Sample)
Date: Wed, 18 Oct 1995 15:46:08 -0400
Organization: Enterprise Solutions Ltd

In article <all-1810951532460001@192.0.2.1>, [e-mail] (Timothy C.
Delaney) wrote:

> I specified 2 bit depth because every monitor which
> supports colour will support 2 bits of it

This is not true.  I am currently using a video card card which only
supports 8 bit colour.

---------------------------

End of C.S.M.P. Digest
**********************